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(57) Abstract 

An authentication system with an ability to effectively implement a system for providing short-lived certificates is described. A key 
distribution center (ICDQ (116) generates and stores public private key pairs and certificate templates. A user is assigned a user public 
private key pair which is stored in the KDC (1 16). A user (1 14) who authenticates to the KDC (e.g. using a passwonl according to, e.g., 
a keiteros system) prompts the system to recertify the user's public key by generating and signing a short-lived certificate. 
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CLIENT SIDE PUBUC KEY AUIHENTICATION 
METHOD AND APPARATUS WITH SHORT-LIVED CERTMCATES 

5 The present invention is directed to a public key authentication system and, in 

particular, to a system making it practical to implement client side public key 
authentication. 

BACKGROUND INFORMATION 

10 One of Oe eadiest infimnatioa security systems was the development of ciph^ 

and systems of encryption and decryption for the purpose of assuring privacy 
(protecting information from unauthorized readers). More recently, and especially 
with the introduction of electronic communication and comput^-based information 
systems, information security systems have also been used for other purposes such as 

IS authmtication (assuring that a message truly originated at its purported origin) and 
authorizaticm (preventing access to hardware, software or data by unauthorized 
persons). The present invaiticm, although having applicability or relationships in many 
areas of information security, is most apparently directed toward client side public key 
authentication. Typically, after authentication has occurred, the authentication can 

20 form a basis for later decisions, such as making access control decisions. 

Many security systems are fundamentally related to systems of data encryption. 
The relationship of encryption to informaticm privacy is apparmt, although systems for 
encrypting and decrypting data have developed to include many elaborate schemes. 
Encryption can be rdiated to identification and authentication in a number of ways. 

25 Most apparentiy, if tile recdver of an encrypted message trusts that only one other 
person possesses the by which the message was encrypted, tiien identification and, 
to some extent, authentication, is achieved upon successful decryption. By using 
encryption for autiientication purposes, its role in access control is apparmt since 
control to a resource can be predicated upon authentication of the person seeking 

30 access. In a password-based autiientication system, encryption may play a role in 
avoiding disclosure of passwords to unauthorized parties (such as by encrypting 
passwords before they are transmitted or stored, or transforming die password into a 
symmetric key and using it in an encryption based protocol to auth^ticate the user). 
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Encryption systems are often categorized into secret tey ("symmetric key") 
systems and public key ("asymmetric key") systems (sometime called a public*key 
private-k^ system), although that are other systems, as well. In a typical secret or 
symm^c key system, the same key is used for both encrypting and decrypting. In 

5 this system, it is important to maintain secrecy of the key, (albeit a shared secret) e.g., 
such that only authorized p^^ns have knowledge or possession of the shared secret 
key. Thus, one of the difficulties with the secret key system is maintaining key 
secrecy. Another problem is key proliferation. If a party wishes to have private 
communication with two or more oth^ parties but does not necessarily wish all parties 

10 to have access to all such communications, it will, in general, be necessary to have a 
different secri^ key shared between each pair of persons. Maintaining and distributing 
such keys becomes unwieldy in large organizations. One approach is to establish a 
trusted third party (TTP) in such a fashion that would require each party to have only 
a single k^: that between himself and die TIP, with tiie TTP acdng as an inters 

IS to establish any particular desired conmiunication channel. This system, while useful 
for many purposes, presents difficult problems of how to assure security of the TIP 
itsdf and maintaining the host's key secret. One implementation of a TTP which has 
adiieved some degree of success is that g^erally known as kerberos, described more 
thoroughly below. In general, a "kerberos-like system," as used herein, refers to 

20 kerberos and any trusted third party system that shares symmetric keys with users and 
sovices. Although a kBrbax)s-like system has been found highly useful in a number of 
situations, it is believed that previous kerberos-type systems typically have not been 
dq)k)yed so as to provide advantages associated with public key systems (such as, e.g. , 
digital signatures). 

25 In a public key (PK) systm, two corresponding ("asymmetric")keys are used 

in connection with protecting information. Information which is oicrypted with one 
of the two keys can be decrypted only with the other key. In some public key systems, 
dther of the two keys can be used to encrypt and the other key to decrypt. In other 
systems, one key must be used only for encryption and die other only for decryption. 

30 One important feature of public key systems is that it is computationally infeasible to 
use knowledge of one of the keys to deduce the otfa^ key. In a typical public key 
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system, each user of the system possesses a set of two such keys. One of the keys is 
maintained private while the other is freely published. If a sender encrypts a message 
with the recipient's public key, only the intended recq>ient can decrypt die message 
(since only the recipient is in possession of the private key corresponding to die 

S published public key). If the sender, before performing the above encrypticHi, first 
encrypts the mesage with die sender's private key, die recipient, upon performing first 
a decryption (using the recipient's private key), then a decryption on the result (using 
die sender's public key) is assured not only of privacy but of audientication since only 
the sender could have encrypted a message such that die sender's public key 

10 successfully decrypts it. In one digital signature scheme, a one-way hash is first 
applied to a message and die hash of die message is encrypted widi die sender's private 
key. 

In diis scenario, die d^ree of confidmce that die recipient has in die source of 
die message depends on die d^ree of die recipient's confidence that the smder's public 

IS key corresponds to a private key that was possessed only by the sender. In many 
current systons, a number of generally well-trusted certification authorities have been 
established to provide dusd^ree of confidence. In the system currendy in widest use, 
dieseaudiorities provide public key certificates. Under die most widely used certificate 
standard (Standard X.S09 devdoped by die International Standards Organization (ISO) 

20 and die Comit6 Consultatif Internationale Telegraphique et Telq)honique (CCITT)), 
such certificates include a public key, the name of the person who possesses or is 
associated with the public key, and odier information which may, e.g., include an 
expiration date, all of which are digitally signed by a trusted party (and are thus in 
encrypted or odierwise modified form). The digital signature may be provided, e.g. , 

25 acccHding to the digital signature standard (DSS) (National Institute of Standards and 
Technology (NISD)). Typically, a digital signature involves s^plying a one-way hash 
and dim encryptiing widi the private key of, in this case, the certification audiority. 
Such digital signature is provided using die private key of the trusted party which, in 
turn, is audienticated using die trusted party's certificate signed by yet anodier trusted 

30 party, so that there may be a multi-levd hierarchy of trusted parties. 
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Although public key systems are used in a number of situations, including 
certain Internet browsing situations, experimce has shown that public key systems can 
have their own difficulties. To provide an acceptable level of security, the key which 
a user maintains secret is not feasible to rmember (typically being a large number such 

S as a 1024-bit binary number) and thus, to be practical, must be stored, making it 
vulnerable to breach of security and, in many systems, requiring use of a particular 
piece of hardware (e.g., a Smartcard or, in some cases, a particular compute). 

In oat previous system, a Smartcard formed part of an authmtication system. 
A number of Smartcaid systems and uses are known. For example, the Secure Socket 

10 Layer (SSL) protocol requires a digital signature for a client application to establish 
communication with certain services. In some environments, a Smartcard will hold 
information used to provide such a digital signature, so that users can access such 
resources if they possess an appropriate Smartcard (and without the need to, e.g. 
memorize a key). Other Smartcard authentication procedures using public and private 

IS key pairs are also known. The principle Smartcard interfaces currently in use are 
PKCS #11 (Public Cryptography Standard, RSA Data Security, Inc.) and PC/SC 
(Personal Conaputer/Smartcard). 

As noted above, a certificate is typically provided with an expiration date. Such 
expiration dates typically are on the order of a year or more from issuance, thus 

20 making certificates, in current systems, relatively long-lived. There are number of 
reasons for this. One of the features that makes a public key system attractive is its 
ease of use, and it would be counter to this goal if users had to obtain key pairs and 
publish new public keys on a very frequent basis. Nevertheless, in some 
circumstances, it is desirable to revoke a previously published cmificate. For 

25 exanqde, a public key pair which is used to control an employee's access to sensitive 
company information might be revoked when the employee leaves the company. 
Accordingly, previous public key systems have typically come to rdy on checking 
certificates against a c»tificate revocation list (CRL). The X.509 standard provides 
an example of CRL rq)resentation. Unfortunately, this requires distribution, e.g. 

3D intranet- or Internet-wide distribution, of CRLs, and requires an additional checking 
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or comparison step. These items can be burdensome or even render the system 
infeasible in relatively large enterprises or networks. 

Another difficulty associated with public key systems is distribution and 
management of the private ki^s« For example, as a company hires new employees, it 
S may want to provide some employees with public-private key pairs, but it becomes 
problematic to distribute the private keys in such a manner as to avoid revealing the 
private keys to G6\er parties. Although employees* private keys should remain private 
if they are to serve the intraded purpose, there are circumstances where a company 
may need to access such keys (e.g. to obtain company-owned information which was 

10 encrypted by a now-deceased employee). However, maintaining a employees' keys, 
e.g., in escrow would typically involve substantial management effort and expense. 

Accordingly, it would be useful to provide a system in which public key 
technology can be used, e.g., for securing computer networks while reducing or 
eliminating the burden of the CRL-checking system, without compromising security 

IS (e.g., form dq>arted employees or others who, under a conventional system, would 
have thdr certificates revoked). It would also be useful to provide a system which 
reduces or diminates the effort and expense associated with private key distribution and 
management. It would further be useful to provide a public key system in which the 
goal of private key storage can be achieved while reducing or eliminating the hardware- 

20 dqiendence and/or security risks associated with previous systems. 

Additionally, it would be useful to provide sudi an improved public key system 
while taking advantage of features of already-used systems to minimize the amount of 
devdiqmient, programming and changes to current systems in order to implement such 
feaniies. 

25 

SUMMARY OF THE INVENTION 
The present invention provides a systm for automatically generating short-lived 
public key certificates (PKC), i.e. with a validity period less than 1 month preferably 
lesstfian 1 week, more preferably less than 1 day and even more preferably less than 
30 about 12 hours, e.g., for session-oriented authentication or other security purposes, 
sudi as authorization. In one embodimmt, eadi time a us^ authenticates using a first 
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authentication system (e.g., every time a user logs onto the system and authenticates 
him or herself), a new but short-lived PKC will be generated and delivered to the user. 
It is antidpated that typically, the public key will be re-catified relatively frequently 
(e.g. every 8 hours, every workday, etc.); the public-private key pair itself remains 
5 unchanged, and is relatively long-lived (e.g. with a lifetime of about 1 year or more). 
This newly generated PKC can then be used in a fashion similar to that for which PKCs 
were used in previous systems, including systems for controlling access to resources 
such as web pages or other resources. 

In one embodiment, the system not only delivers the short-lived PKC but also 

10 delivCTs the private key corresponding to the PKCs public key. This relieves the usct 
from having to be responsible for storing a public key or from being restricted to using 
particular hardware on which die private key is stored (although such a hardware-based 
approach could be used if preferred). Because the PKC is short-lived, it is possible to 
adiieve a relatively high degree of trust without the need (or with a reduced need) for 

15 prxessing CRLs. In the case of, for example, a departed employee, the system will 
be configured to refuse to issue any more (short-lived) certificates for such employees 
and because previously-valid issued certificates will have expired (or will shortly 
expire), checking against a CRL is unnecessary. 

In one embodiment, since both the private key and public key are returned to 

20 the computer of the person seeking access, it is possible, if desired, to implement a 
simulated Smartcard in which the private key and public key, cached locally in the 
computer of the person seeking access, are used to simulate the presence of a physical 
Smartcard. For example, in connection with a PKCS #1 1 interface, the simulation can 
take the form of fiilfilling Smart API Calls such as, e.g., C-SIGN, C-VERIFY. In this 

25 way, the present invention can take advantage of relatively mature application 
prpgranuning interfaces (APIs) for Smartcards to implement a public key-based, client 
side authentication, without the need for actual Smartcard hardware (such as without 
the need for users to obtain and carry actual Smartcards). 

In one embodiment, a TIP system which may be, for example, similar to a 

30 koberos ^stem, can be ad^ned for use as die short-lived certificate generating system. 
Such a system combines some of the advantages of a kerberos-type system, such as 
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bdng password based and toleiant of users who log on at different computers ("roving 
users**) with certain advantages of a public key system (such as facilitating access to 
resources whidi aie protected via a public key infxastiucture or system) while avoiding 
the above-noted difficulties with public key systems, such as private key distribution 
S and management difficulties^ the need for maintaining and using CRLs and storing 
private keys in reiativdy insecure or inconvenient fashions. 

BRIEF DESCRIPTION OF THE DRAWINGS 
Fig. 1 is a schematic block diagram of a kerberos-type system according to 
10 previous procedures; 

Fig. 2 is a flowchart of a public key/Smartcard authentication system according 
to previous systems; 

Fig. 3 is a flow chart depicting certificate generation and use according to an 
embodiment of the present invention; 
IS Fig. 4 is a blodc diagram of certain componrats of a system illustrating use of 

the procedure of Fig. 3; 

Fig. S is a block diagram of a syston for use with a simulated smartcard and/or 
a hardware smartcard, according to an embodiment of the present invoition; 

Fig. 6 is a block diagram of a system for use with a simulated smartcard and/or 
20 a hardware smartcard, according to an embodiment of the present invention; 

Fig. 7 is a block diagram illustrating a system for logging in to a simulated 
smartcard, according to an embodiment of the preset invention; 

Fig. 8A and 8B are block diagrams illustrating examples of how a system 
according to the presmt invmtion can provide support for third-party Public Key 
25 Infrastructures (PKI); and 

Fig. 9 is a block diagram illustrating user ouollmrat in the context of a 
emulated smartcard system, according to an embodiment of the present invmtion. 



30 



DETAILED DESCRIPTION OF TEIE PREFERRED EMBODIMENTS 
Before describing features of embodiments of the present invention, certain 
features of previous systems will first be described. Fig. 1 dq)icts an authentication 
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piooeduie using a kecberos system. Although the kerberos system uses a passwoid for 
autteatication, the system is particularly secure because it never transmits passwords, 
either encrypted or unencrypted, over the network. In the depicted embodiment the 
system can provide a number of different services, including a ticket-granting service 
5 (described below) and various other services that may be desired by the user. In the 
depicted embodiment, the person who desires to use a particular resource or service 
112 (which may be, for example, a software service such as a particular application 
program, may be data, may be a particular hardware resource or combination thereof) 
attempts to Ic^ onto the system, entering (usually in response to a prompt) a password 

10 known only to the person being authenticated. Preferably, for a typical user session, 
this is the only time the user will need this password during a (normal-length, e.g. 8-10 
hour) sessum (although, if desired the system can be configured to require re-input of 
the password to perform certain tasks, such as administration tasks on the security 
system). The person makes the log-on attempt using a client compute 1 14 coupled, 

15 e.g., via a local area network (LAN) or other communication system to a key 
distribution center (KDQ 116. In response, the client 114 smds a request message 
(AS-REQ) 118 to the KDC. The request 118 indicates the name of the person 
requesting the service but does not include the password. The KDC 116 responds 122 
wifli an encrypted "ticket granting ticket" (TGT) (AS-REP). The ticket granting ticket 

20 includes two main components: a tick^ for the client to use the ticket granting service 
(the majority of which, including the session key, is encrypted widi the key of the 
ticket granting service) and a session key for die client and ticket granting service, 
enoypted with the client key. When the user wishes to begin using a particular service 
112, an additional transaction with the KDC is needed. The dxeni compute 114 

25 transmits a ticket request 124 (TGS-REQ) to the KDC 116. The request includes a 
number of components including an authenticatcnr (generated by the client) for the client 
to use Ae sovice, encrypted with the session kBy(the sessicm key is ^ 
the ticket for a client to use the ticket granting s^ce, die majority of which is 
encrypted with the key of the ticket granting service (botii of whidi were included in 

30 the ticket granting ticket 122) and die name of the s^ce 1 12. In response, die key 
distributicm center 116 transmits to the client a ticket 126 (TGS-REP) (the majority of 
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which is encrypted) which contains a ticket for the climt to use the server, at least 
partially encrypted with the server's key, and a copy of the session key, encrypted with 
the session key diat is shared between theclientand the ticket granting server. Atthis 
point, the client now has sufficient itrais to gain access to the s^ce 112 as desired. 
5 TTus is achieved by transmitting from the client to the service 112 a message containing 
an authoiticator and a ticket. In response, the service provides the desired server 
response to the client. The service 1 12 can treat the ticket as authaitic because only 
the KDC and the savice 112 share the secret key with which the ticket is encrypted. 
As depicted in Fig. 2, a public key system operates in a substantially different 

10 form. Typically a user generates a public-private tey pair 202. The user stores the 
private key 204 in any of a number of fashions, such as in a file on a client computer or 
onaSmartcard. Sudi storage in previous systans is bdieved to raise difScuhies. Storing 
in a file located on a particular computer impairs "roving users" since the user can only 
use or access his stored private key on the particular computer where it was stored. That 

IS is, the system is inconvenient or infeasible for users who need or desire the ability to log 
onto any of a plurality of different compute (e.g., any of a plurality of nodes in a local 
area network or other networic) and still be able to use a public key system-controlled 
resource. It is fiutho* believed that storing private keys in a file on a computer, even 
if protected by encryption or other measures, represents a security vulnerability of the 

20 SjfStenL Storage of a private key on a Smartcard is at least theoretically compatible with 
roving users but in many situations is infeasible because of the cost and administrative 
overiiead involved in equipping a plurality of machines with Smartcard readers and 
distributing Smartcards to various users. 

The user submits the public key for certification to a trusted entity such as a 

25 certification authority (CA), e.g. via a PKCS #10 request. Upon verifying the requestor's 
identity (out of band) the CA issues an X.509 certificate to certify the user's public key 
212. The certificate is then sent back to the user and typically will be publicly available, 
such as by publication in a directory such as an X.SOO or LDAP (Lightweight Directory 
Access Protocol) directory, both well-know to those of skill in the art. The CA also 

30 periodically issues certificate revocation lists (CRL's) 214 as described above. One 
medianism for distributing CRL*s is via LDAP. 
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In certain previous systems, a user wishing to access a resource would retrieve the 
private key (typically in an automatic &shion) 218. Using any of a number of systems 
known in the ait for public key system based authendcation, a resource control device will 
verify, using e.g. the user's public key (certified by the CA) that the user has been properly 
S and correctly identified 222. Because of the long lifetime of certificates in previous 
systems, the resource control device will then perform a comparison with the CRL in 
order to detennine whether the certificate has been revoked 224. As noted above, the 
comparison 224 represents an additional step in the process of controlling access. 
Additionally, there is an administrative cost in producing, distributing, storing and 

10 otherwise tracking CRLs, particularly when CRLs are promulgated with sufiBcient 
firequency to detea use of even recently-revoked certificates. 

In order to address these and other problems, in previous systems, one 
embodiment uses a certificate generation system as depicted in Fig. 3. Althou^ as will 
be zppmtA to those of skDl in the art after understanding the present disclosure, a number 

IS of dififerent systems could be used for generating certificates, in one embodiment a 
modified kerberos-like ^stem is used. In the embodiment depicted in Fig. 3, one of the 
components of the modified kerberos-like system is a key distribution center (KDC) 416 
(Fig. 4). The key distribution center 416 can be similar to that described in connection 
with Fig. 1 but modified (e.g. provided with cUfferent software) for the procedure 

20 described bdow. In the system and procedure of Eg. 3, initially (e.g. at installation time), 
the KDC 416 will generate a public-private key pair 3 12. The system will also generate 
a certificate template (such as an X.509 certificate) 314. The KDC 416 will then use the 
KDCs private key to sign the template. These steps 312, 314, 316 are substantially 
similar to procedures followed by root certification authorities (but not, typically, by 

25 network servers or KDCs) in previous systems. When a user registers, the client 
administration will generate a long-lived public-private key pair associated with that 
particular user and will store 318 the key pair in the KDC 416, associated with an 
identifier of the user. When the user begjns a session, such as by logging on to a network, 
the user will enter a password, causing the client 1 14 to send 322 an AS-REQ message 

30 118 to the KDC 416, as described previously in connection with Fig. 1. In the 
embodiment of Figs. 3 and 4, in response to the AS-REQ 118, the system will re-certify 
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the user's public key. Specifically, the system will generate and sign an X.S09 certificate 
fi)r the user 324. Thus» ^^diereas in previous pubUc key systenis, a CA would geneme and 
publish a certificate once (upon initial issuance) according to the system of Figs. 3 and 4, 
the system will generate a certificate containing the user's public key multiple times, 
S typically, each time the user logs on to the ^stem resulting, overtime, in a sequence of 
certificates for this user. 

An additional difference between the present system and typical public key systems 
is that the certificate is short-lived, i.e., contains an expiration time/date which is 
significantly less than the one- to two-year (or longw) certificate expiration date in 

10 previous public key systGns, prefwably expiring in less than six months, or preferably less 
than a month, more preferably less than a week, even more preferably less than 24 hours, 
and yet more preferably expiring less than 12 and preferably around 8-10 hours after 
issuance. It is anticipated that the e7q)iration date of such short-lived certificates will vary 
with the needs of the company or other enterprise implementing such systems, and 

IS preferabfy one or more normal or de&utt lifetimes for certificates can be established, e.g. 
by a system administrator (following proper auth^cation). It is antidpated that 
certificate lifetime policies be set so as to provide certificates with lifetimes sufficiently 
short that checking against CRL's can be reduced or diminated without significantly 
di m i n is h i ng overall security. According, each time the system generates (or re-signs) a 

20 certificate for ttus user (i.t. a certificate containing the user's public key) the certificate v^l 
have a different expiration time. Typically, a new certificate (based on identical public 
key) will generate only after the expiration of the previous certificate, although other 
protocols could also be used. Thus» the result of the present system will typically be 
issuance of a series or sequence of certificates for any given user (typically on a daily or 

25 woricd^ basis) but in which the certificates for this user are not completely identical, i.e. 
will differ ftom one another with regard to the expiration time-date (but, for a given user, 
will have identical public keys). This is in contrast with previous public key systems in 
whidi a certificate, once it was issued, was not thereafter issued again for the same public 
key in a difTerent form or with different information (specifically with different &q)iration 

30 time/date). 
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In one embodiment, other data may be added to or modified in the series of short- 
lived certificates for a user. For example, data indicating which resources a given user 
is authorized to use (or other authorization data) can be included in the short-lived 
certificates. One example of such authorization information is information indicating one 
5 or more user groups with vAich a user is afiBliated, e.g. whose members are authorized 
to use certain resources. It is believed inclusion of such authorization data, which 
typically may diange on a rdativety short time fi^e, (e.g. days or weeks) would not h^ve 
been appropriate for inchision in (and, it is believed, was not included in) previous Gong- 
lived) certificates, but is feasible for inclusion in short-lived certificates according to 
10 embodiments of the present invention. 

After generation of the certificate, the system will then transmit or deliver 326 the 
certificate 422 to the dient 144. In one possible embodiment, the delivery is made as part 
of the (mocfified) AS-REP re^nse, analogous to that described above in connection with 
Rg. 1. 

IS After the user has logged on and has received the certificate 422, anytime during 

the valid lifetime of the certificate that the user wishes to authenticate to a resource, 
including a public k^-controUed resource 418, the user can do so, e.g. using the 
certificate, typically without the need to enter the password again. After the short-lived 
certificate has expired, in order for the user to authenticate to a resource, the user will 

20 need to repeat the procedure described above in order to obtain another short-lived 
catificate, thus typically requiring re-entering the password. 

Preferably, the system delivers not only the certificate, but also the private key of 
the user 328 ^ e. which corresponds to the public key on which the certificate is based), 
preferably protected by a shared secret such as a session key generated by the kerberos- 

25 like system. In this way, the user is able to retrieve the private key for use as described 
in Fig. 2 (218) but without having to store the private key in a file on the client computer 
1 14 (wiiere, as noted above, it may be relatively vukierable). Additionally, by providing 
a central location for storing users' private keys, central administration of private keys 
(and implementation of key policies) is made feasible, in contrast to previous PK systems, 

30 which wore typically based on a paradigm of private keys bdng widely distributed (i.e. 
individually stored by individual users). Moreover, since, according to the present 
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system, a user can use any of a plurality of computers to log onto the system using his or 
her password, this system supports roving users, but without the requirement for a 
pbysicai Smaitcard. The cGent computer 1 14, being in possession of both the private 
and the certificate, can access 332 a public key controlled resource 424. 
5 A public/private key pair may be used in connection with authenticating to a 

nund)er of resources. As one example, an access control decision can be made based on 
an authentication process which involves use of a Smartcard, e.g. using a hardware 
Smartcard 516 in connection with a Smartcard interface S18 such as a PKCS #11 
appUcation programming interfiice 5 12 (Figs. 5 and 6). However, the present invention 

10 affords an additional opportunity. According to the embodiment generally illustrated in 
Fig. S, it is possible to provide a simulated Smartcard/Smartcard interface in place of, or, 
as illustrated, in addition to, the hardware Smartcard 516 and interface 518. From the 
perspective of the £4)plication S14 (such as, for exanq)le, a browser 517) and API 512, 
there will be no difference between a simulated Smartcard/Smartcard interface 522 and 

IS the hardware Smartcard/inter&ce 5 16, 5 1 8. When a user is log^ng into the card (e.g. 
using the C-LOGIN call in the PKCS #1 1 API), the user's password will be used to 
authenticate to the KDC 416 and retrieve the private key and a fi^hly generated X.509 
certificate 422. These credentials are then cached locally 524 (or remotely). From the 
cache 524 the credentials may be used to fulfill Smartcard API calls (e.g. C-SIGNf, C- 

20 VERIFY). The sf>[TOachofFigs. 5 and 6 permits transpaiem access to an appUra^ 

via a PKCS #11 API, i.e. using a relatively mature API but without the cost and 
administrative overhead associated with hardware Smartcards. 

As illustrated in Fig. 7, in one example, a process for logging in to a simulated 
smartcard may begin when a client application S 14 uses a standard API such as PKCS 

25 #1 1, MS-CAPI, CDSA and the like, to initiate log on of user into a smartcard. Preferably 
the process of the pres^it invention is transparent to the client application 5 1 4 in the sense 
that the messages and/or data sent from and received by the client application during the 
process will be the same regardless of whether the client application 5 14 is logging on to 
the simulated smartcard as depicted in Fig. 7 or logs on to a physical smartcard. The 

30 particular interfile 512 vAich is used will typically depend on what client application 514 
is performing the login (e.g. it is likely a Nficrosoft* would use an MS-CAPI interface 
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wfaSe Other browser or appUcations mightily In the 

illustrated embodiment, the simulated smartcard client 714 implemented with software 
typically reading on a (£ent side computer) will authenticate to 716 a security server 718, 
typically an authentication service such as a Kerberos-like authentication service. 
S Typically, the Emulated smartcard client 714 will request a password and/or login name 
fiom the user before formulating and sending an authentication request 716. The security 
servor 718 responds by sending 722 authentication credentials to the simulated smartcard 
client 714. The authentication oedentials which are sent 722 may include those described 
above in connection with the embodiments of the present invention and/or previous 

10 systems. However, preferably the information sent 722 is suflScient to permit the 
simulated smartcard client 714 to said a message 724 to a simulated smartcard server 726 
sufficiait to authenticate to the simulated smartcard server. Typically the information 722 
sent to the simulated smartcard client 714 will include a tickei (generally as described 
above) for the smartcard s^ce. In response to receipt of an autiienticated request 724, 

IS the simulated smartcard server 726 returns a (preferably encrypted) smartcard image 728. 

As used herein, the "smartcard image'' includes at least some information which, 
in a plq^sical smartcard system, would be stored on or derived from a physical smartcard. 
Examples inchide public keys, private keys, symmetric keys, certificates and the like. In 
one erhbodiment, the smartcard image is encrypted, for example with a private key. The 

20 simulated smartcard client 714 will then decrypt the smartcard image. The decrypted 
image may contain, e.g., public k^ private keys, qmimetric keys, c^tificates and similar 
information. Some or all of the mformation (prefoably including especially sensitive 
information sudi as a private key) may be encrypted under a password known only to the 
end user. 

25 In gaieral, in Fig. 7 through 8, blocks diown underneath the client application 514 

are items which are client side items, i.e. which use or constitute software residing, 
typically, on a PC or other computer used by an end user, while items on the right side of 
the figure represent server-side items i.e. which use or constitute software residing at 
remote locations such as remotdy located network servers. Although, in the embodiment 

30 depicted in Fig. 7, a security server 71 8 and simulated smartcard server 726 are shown as 
separate blocks, it is also possible to configure a system in which one or more of the 
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components depicted as separate blocks are, in fact on a single sover computer, e.g. in 
.^ndiidi the security server 718 and simulated smartcard server 726 are located on a single 
server conqniter. It is possible, in this situation, to combine steps 2, 3 and 4 so that the 
simulated smaitcard dient 714 sends an authentication request 716 to the security 
S server/amulated smartcard server which responds by sending a (preferably encrypted) 
smartcard image 728 back to the simulated smartcard cli»t 714. 

After receiving the smartcard image, the smartcard client 714 will then check for 
expired public key certificates on the (decrypted) anartcard image. If an expired 
certificate is found, the simulated smaitcard cUent 714 will submit a re-c^ification 

10 request 732 to a server-side certification authority 734. Typically certifications returned 
to the simulated smartcard client 714 will be ^ort-lived c^tificates generally as described 
above. The simulated smartcard client 714 will then use the objects on the smartcard 
image to fiilfil cryptogr^hic operations provided by the cryptographic API's 512 
responding 736 to the client application 514 in a manner substantially identical to the 

IS manner of response that would have been provided had a phyacal smartcard system been 
used. 

After a simulated smartcard login as depicted in Fig. 7, further smartcard 
operations may be involved in executing the client application 514. Figs. 8A and 8B 
provide two (of many) possible examples of sudi fimher (^wation. In the «ample of Hg. 

20 5 A, following login and download of the smartcard image 812 (performed generally as 
described above in connection with Fig. 7), the client application 514 may, e.g., generate 
or store public key credentials 814 (typically using standard cryptographic API's 512). 
Such public key credentials are, in die embodiment of Fig. 8 A, handled in a &^on which 
is transparent to the client application 514. In the depicted embodiment, the simulated 

25 smartcard client 714 will send a message 816 to the simulated smartcard server 726 to 
update the simulated smartcard image on the server side. This illustrates one feshion of 
incorporating a third party's credentials in the system of the present invention and 
accordingly providing support for third party certification authorities. 

Fig. 8B provides another example. In the embodiment of Fig. 5 A the client 

30 q)plication 5 14 communicates with a third party certification authority 822, 824 which is 
neither on a client machine nor a server of the present security system. For example, the 
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client application 514 may contact a third party certification authority to get certified. 
However, after such communication 822, when the client 514 sends a message 814' for 
smartcard storage, the present system provides for simulated smartcard storage, in a 
manner similar to that described above in connection with Fig. 8A, by sendmg the 

5 information 816' prime to the simulated smartcard server 726 for storage. 

Fig. 9 illustrates use of the system, according to an embodiment of the present 
invention, fi)r enrolling new users in the sinmlated smartcard system. In the embodiment 
of Fig. 9, an administrator, e.g. using an administrator server 912, prepares a certificate 
template (pr^erably assisted by software for generating such templates) which is sent for 

10 storage 914 on a simulated smartcard server 726 (or a storage device 916 associated 
thwewith). The template specifies at least some of the components of the certificate for 
use in the syston. Typically, the template will contain, e.g., the user's distinguished name, 
the issuer's distinguished name and the like. An initial password is generated for a new 
user and stored on the security server 718 (or a storage device couple therewith) 

15 preferably resetting the password 722 such that after the us^ preforms an initial log on, 
the password will be flagged as being in an expired state (thus forcing the user to change 
the password). 

The generation of a new public-private key pair for the user could be performed 
either on the dient side compute 714 or on a server (e.g. 912). Client side key 

20 generation might be used when it is desired to reduce the computing load on server 
con^Riters. However, particularly in situations where many users are being added at one 
time, it may be usefiil to generate the new pairs on the server side 9 1 2 to fecilitate setting 
up the system to accommodate a number of new users. The passwords discussed above 
are (fistributed to the various users. Preferably this is done out-of-band (without 

25 transmitting the password over the computer network, such as by providing the password 
m a personal meeting, over the telephone and the like). As each new user logs into the 
system for the first time 922, the user preferably will be required to change his or her 
password (as described above). If the key pair was not previously generated on the server 
side, the simulated smartcard client 714 will generate the k^ pair. The smartcard image 

30 is then downloaded to the client, e.g. using a procedure 812 similar to that described 
above. The keys are then generated and writt«i back to the smartcard image on the server 
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side, e.g. using a procedure 816 amilar to that described above in connection with Fig. 
.8A. 

In light of the above description, a number of advantages of the present invention 
can be seen. The present invention provides a turnkey sohition making public key 
S authentication feasible. In one embodiment, the present invention employs a symmetric 
key authentication to aiable use of an application which may be protected by an 
asymmetric key systan. The present invention makes it practical to implemait client side 
public key authentication by solving the private key management and certificate revocation 
problems. The invention provides for public key authentication without the need for (or 

10 with reduced need for) CRLs and/or without the need for client-stored or smartcard- 
stored private keys. The present invention provides for relatively fi-equent public key 
reccrtification (e.g. eveiy work day) without the need for firequent regeneration of new 
key pairs, which is a computationally expensive operation. The present invention can be 
implemented using (in modified fashion) certain previous systems or standards such as a 

IS modified kerberos and/or PKCS #11, MS-CAPI or CDSA implementations, tiierd)y 
taking advantage of certain relatively mature or developed systems (or features of such 
systems) while avoiding certain disadvantages previously con^dered to be an unavoidable 
part of such ^sterns. The present invention provides an opportunity to implement central 
administration of both a public key ^stem and kerberos system to accommodate both 

20 types of uses. The present invention pro>ades a single system which can both use or 
implement a public key system and act as a certification authority. 

A number of variations and modifications of the present invention can also be 
used. Ahhough the depicted and described embodiments employ a TTP system such as 
a kefberos-type system for generating and ddivering short-lived certificates, other systems 

25 could also be used for generating and delivering short-lived certificates. It is possible to 
provide a system in which differort fedlities are used for generating and for delivering the 
cotificates. It is possible to provide a system in which delivery of a short-lived certificate 
is not necessarily accompanied by delivery of a private key or a kerberos ticket. 

It is, in general, possible to use some features of the invention without using 

30 others. For example, it is possible to provide a system which generates short-lived 
c^tificates without using a simulated Smartcard system or vice versa. 
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Although it is antidpated that the short-lived certificates will be used in connection 
authentication, it is possible to use short-lived certificates in connection with other 
security measures^ authorization, encryption or other privacy measures and the like. 
Although it is anticipated that the diort-lived certificates will be used primarily in 
connection widi session-oriented applications (such as Intern^ sites, browsers or servers 
controlled using a public key system), it is at least theoretically possible to use short-lived 
certificates in connection with oth^ uses such as store and forward (e.g., secure electronic 
mail) uses. Although an example has been provided describing use of Smartcards or 
simulated Smartcards in connection with intranet or Internet browser access, Smartcards 
or simulated Smartcards can be used in connection with other items, such as electronic 
mail ("e-mail"). Although use of a KDC or other system for generating short-lived 
certificates has been described, it is possible to configure thqr system to issue moderate- 
life or (standard) long-lived certificates. Although certificate and/or private key delivery 
is described as occurring as part of a kerberos AS-REP message, it is possible to provide 
for deliveiy separately firom the AS-REP message. If derired, the system can be 
configured to deliver only private key and certificates to the dient (i.e. without delivering 
tidcet granting tidcets or other tickets), or the system may be configured to allow the user 
to specify indiether delivery of both public key credentials and kerberos tickets, and/or 
both certificate and private key is needed or desu-ed. 

AltfKHigh the invention has been described by way of a preferred embodiment and 
certain variations and modifications, other variations and modifications can also be used, 
the invention being defined by the following claims. 
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What is claimed is- 

1. A computer-implemented m^od for issuing public key certificates for a 
user in a network ^ch includes at least a first client computer coupled, by said network 
to at least a first key distribution computer configured to output tickets according to a 

S ticket protocol, the method comprising: 

storing, in a memory accessible to said key distribution computer, at least a public 
key of said user, 

receiving in said client computer at least a first password of said user; 
verifying validity of said password in said client computer, 
10 transmitting from said client computer, over said network, to said key distribution 

computer, at least a first message which inchides an indication of the identity of said user; 

transmitting at a first time, in response to said first message, from said key 
distribution computer, over said network, to said client computer, both a ticket according 
to said tidcet protocol and a short-lived public key cmificate containing said public key 
15 of said user. 

2. A computer-implemented m^hod as daimed in daim 1 wherein said ticket 
protocol is a kerberos protocol. 

3. A computer-implemented method as claimed in daim 1 fiirth^ comprising 
transmitdiig, in response to said first message, from said key distribution computer, over 

20 said network, to said client computer, a private key of said user corresponding to said 
public key of said user. 

4. A computer-implemented method as claimed in daim 1 wherein said short- 
lived public key certificate has an expiration time less than about one week after said first 
time. 

25 5. A computCT-implemented medKxl as claimed in daim 1 wherein said short- 

lived public k^ certificate has an expiration tune less than about 12 hours after said first 
time. 

6. A computer-implemented method as claimed in claim 1 fiirther compriang 
using said short-lived public key certificate to provide authentication of said user. 
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7. A conqmterHii^lemented method as claimed in 1 further comprising 
. using said short-lived public key certificate for authorizing said user to use a resource 
which is controlled by a public key system. 

8. Acomputer-inq)lemented method as claimed in daim 1 vrfierein said public 
S key certificate is an X.S09 certificate. 

9. Apparatus for issuing public key certificates for a user in a network, the 
network mduding at least a first client computer coupled, by said network to at least a 
first key distribution computer configured to output tickets according to a ticket protocol, 
the apparatus comprising: 

10 a memory, accessible to said key distribution computer, for storing at least a public 

key of said user, 

said client computer and said key distribution computer being programmed to 
recave, in said client computer, at least a first password of said user, 
verify validity of said password in said client computer, 
IS transmit &om said dient computer, over said networic, to said key 

distribution computer, at least a first message which includes an indication 
of the identity of said us^, 

transmit, at a first time, in response to said first message, firom 
said key distribution compute, over said network, to said client computer, 
20 both a ticket according to said tick^ protocol and a short-lived public key 

ctttificate containing said public key of said user. 

10. An apparatus, as claimed in claim 9 wherein said ticket protocol is a 
kerberos protocol 

1 1 . Apparatus as daimed in claim 9, said key distribution con^uter configured 
2S to fiirtl^ transmit, in response to said first message, fi-om said key distribution computer, 

over said network, to said client computer, a private key of said user corresponding to 
said public k^ of said user. 

12. Apparatus as daimed in claim 9 wherem said short-lived public key 
certificate has an expiration time less than about one week after said first time. 

30 13. Apparatus as claimed in claim 9 wherein said short-lived public key 

certificate has an expiration time less than about 12 hours after said first time. 
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14. Apparatus as claimed in claim 9 further comprising using said short-lived 
public key certificate to provide authentication of said user. 

15. AppaxBtus as claimed in daim 9 fiirther comprising using said short-Uved 
puUic key certificate for authorizing said user to use a resource which is controlled by a 

S public 1^ system. 

16. Apparatus^ as chimed in claim 9 wherein said public key cotificate is an 
X.509 certificate. 

1 7. Apparatus for issuing public key certificates for a user in a network \siiich 
includes at least a first client computer coupled, by said network to at least a first key 

10 distribution computer configured to output tickets according to a ticket protocol, the 
method comprising: 

memory means^ accessible to said key distribution computer, for storing at least 
a public key of said user, 

means, coupled to said client computer, for recdving at least a first password of 
IS said user; 

means, in said client computer, for verifying validity of said password; 
means^ coupled to said dient conqnxter, for transmitting &om said client computer, 
over ssud network, to said key distribution computer, at least a first message which 
includes an indication of the identity of said user; 
20 means, m saki key distribution conq)uter, for generating and transmitting at a first 

time, in response to said first message, fi-om said k^ distribution computer, over said 
network, to said client computer, both a ticket according to said ticket protocol and a 
short-lived publickeyc^tificatecontainingsaidpublickey of said user. 

18. Apparatus as claimed in claim 17 finther comprising means for 
25 transmitting, in response to said first message, fi-om said key distribution computer, over 

said network, to said client computer, a private key of said user corresponding to said 
public key of said user. 

19. Apparatus, as claimed in claim 17, wherein said short-lived public key 
certificate has an expiration time less than about one week after said first time. 

30 20. Apparatus, as claimed in claim 17 wherein said short-lived public key 

certificate has an expiration time less than about 12 hours after said first time. 
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2 1 . ^paratus as daimed in daim 17 fijither comprising using said short-lived 
public key certificate to provide authentication of said user. 

22. ^paratus as daimed in daim 17 fiuther comprising using said short-lived 
public key certificate for authorizing said user to use a resource vMch is controlled by a 

5 public key system. 

23. Apparatus as claimed in claim 17 wherem said public key certificate is an 
X.S09 certificate. 

24. A computer-implemented method for issuing public key certificates for a 
user comprising: 

10 storing, in a memory coupled to said computer, a plurality of public keys^ 

including a public key assodated with said user; 

receiving, in said computer, at a plurality of arbitrary times, messages which 
include an identification of said user, 

outputting, in response to each of at least a first plurality of said messages, a 
IS public key certificate for said user including an indication of said public key assodated 
with said user and an indication of an expiration time for said certificate, wherdn a 
sequence of public kgy certificates are output vMch have identical indication of public key 
but different and sequential expiration times. 

25. A computer-implemented method as daimed in claim 24 wherein a private 
20 key of said user corresponding to said public key of said user is output substantially 

whenever said public key certificate is output. 

26. A computer-implemented method as claimed in claim 24 wherein, each 
public key certificate in said sequence has a validity period extending fi-om substantially 
vihen said certificate is output until, the expiration time of said public key certificate, and 

25 wherein each public key certificate in said sequence has a validity period of less than about 
one week so that said sequence of public key certificates is a sequence of short-lived 
certificates. 

27. A conq)uta^- implmented method as claimed in claim 24 wherein each of 
said public key certificates in said sequence has a validity period of less than about one 

30 day. 



wo 99/35783 PCT/US99/00344 

23 

28. A computer-implemented method as claimed in claim 24 wherein each of 
$aid public key certificates in said sequence has a validity period of less than about 12 
hours. 

29. Apparatus for issuing public key certificates for a user compriang: 

S a memory coupled to a computer, for storing a plurality of public keys» inchiding 

a public key associated with said user; 

said computer being programmed to have the capability of receiving, at a plurality 
of arbitrary times, messages which include an identification of said user; 

said conq)uterbdng programmed to output, in response to each of at least a first 
10 phirality of said messages, a public key certificate for said user including an indication of 
said public key associated with said user and an indication of an expiration time for said 
certificate, wherein a sequence of public key certificates are output which have identical 
indication of public key but different and sequential expiration times. 

30. Apparatus as claimed in claim 29 wherem said computer is programmed 
IS sudi that a private key of said user corre^nding to said public key of said user is output 

substantially whenever said public key c^tificate is output. 

31. Apparatus as claimed in claim 29 wherein each public key certificate in 
said sequence has a vafidity period extending from substantially \^en said certificate is 
ou^ut until, the expiration time of said public key certificate, and vAx&rein each public 

20 key certificate in said sequence has a validity period of less than about one week so that 
said sequence of public key certificates is a sequence of short-lived certificates. 

32. Apparatus as claimed in claim 29 wherein each of said public key 
certificates in said sequence has a validity period of less than about one day. 

33. Apparatus as claimed in claim 29 wherein each of said public key 
25 certificates in said sequence has a validity period of less than about 12 hours. 

34. i^paratus for issuing public key certificates for a user comprising: 
memory means, coupled to a computer, for storing a plurality of public keys, 

including a public key associated with said user; 

said computer being programmed to receive, at a plurality of arbitrary times, 
30 messages which include an identification of said user, 
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said conqniter bdng piogranuned to output, in response to each of at least a first 
plurality of said messages, a public key certificate for said user including an indication of 
said public key associated with said user and an indication of an expiration time for said 
certificate, wherein a sequoice of public key certificates are output which have identical 
S indication of public key but difierent and sequential expiration times. 

35. Apparatus as daimed in daim 34 further comprising means for outputting 
a private key of said user corresponding to said public key of said user substantially 
whenever said public key certificate is output. 

36. Apparatus as claimed in claim 34 wherein, each public key certificate in 
10 said sequence has a vahdity period extending fi'om substantially when said certificate is 

output until, the expiration time of said public key certificate, and wherein each public 
key certificate in said sequence has a validity period of less than about one wedc so that 
said sequence of public key certificates is a sequence of short-lived certificates. 

37. A conqniter- inq)lemented method as claimed in claim 36 wherein each of 
15 said public key certificates in said sequence has a validity p^od of less than about one 

day. 

38. A conq)uter-implemented method as claimed in claim 36 wherdn each of 
said public key certificates in said sequence has a validity period of less than about 12 
hours. 

20 39. A computer-implemented method for issuing public key certificates for a 

user comprising: 

receiving, in said computer, a messages which include an identification of said 

user; 

outputting, in response to said step of receiving, a short-lived public key 
25 certificate. 

40. Apparatus for issuing public key certificates for a user comprising: 

a computer programmed to receive messages which include an identification of 
said user and to output, in response to said messages, short-lived public key certificates. 

4 1 . Apparatus for issuing public key certificates for a user comprising: 

30 computer-implemented means for receiving messages vMch indude an 

identification of said user, 
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computer-implem^ited means for outputting short-lived public key certificates 
in reqx)nse to recdving said messages. 

42. In a computer-implemented authentication system configured to 
authenticate users in accordance with a first Smartcard protocol, a method for 

S authenticating to a resource comprising: 

providing a public/private pair of a first user, and 
using said key pair to simulate the response which a Smartcard genres in 
accordance with said Smartcard protocol. 

43. A method as claimed in claim 42 wherein the public key of said 
10 public/private key pair is certified by an unexpired short-lived public key certificate of said 

user. 

44. A computer-implemented public-key certification method comprising: 
obtaining a public-key and private-key pair, 

genmting a series of public-key certificates for said public-key, with a 
IS frequoicy of at least two public-key certificates per year. 

45 . A method, as claimed in daim 44, wherein said fifequency is at least about 
12 public-key certificates per year. 

46. Amethod, as claimed in claim 44, v^erein said finequency is at least about 
five public-key certificates per week. 

20 47. A method, as claimed in claim 44 who-ein said public-key certificates 

include an expiration defining a certificate lifetime of less than about six months. 

48. A method, as daimed in claim 44, whmin said public-key certificates 
inchide an expiration defining a certificate lifetime of less than about one week. 

49. A method, as daimed in daim 44, wherdn said public-key private-key pair 
25 has an expiration defining a public-key private-key lifetime of at least about one year. 

50. A method, as daimed in claim 44, wherein said public-key private-key pair 
has an expiration defining a public-key private-key lifetime of less than about one day. 

51. A method, as claimed in claim SO, wherein said public-key certificates 
indude an expiration defining a certificate lifetime of less than about one day. 
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52. A method, for use in a computer ^stem having at least one dient computer 
and at least one server computer coupled by a communications link, the method 
comprising: 

storing in a memory coupled to said computer system, first infonnation 
S represmting at least some data of a type normally stored on a smart card; 

using a kerberos-like system for password-based authentication of a user to said 
server; and 

retrieving said first information following said password-based authentication.. 

53. A method, as claimed in claim 52, further comprising using said first 
10 information to simulate use of a hardware Smartcard. 

54. A method, as claimed in claim 52, wherein said first information includes 
at least one of a symmetric key, an asymmetric key pair, and a key certificate. 

55. A method, as claimed in claim 44, wherdn said public key certificates 
fiirth^ include authorization information. 

15 56. A method, as claimed in claim 55, wherdn said authorization information 

includes group a£51iation informatioa 

57. A method, as daimed in claim 56, fiirther comprising using said 
authorization information in a resource authorization system. 

58. ^paratus for user authentication comprising: 

20 means for receiving a hardware Smaitcard and using said received hardware 

Smartcard to authenticate a user, and 

means for simulating a hardware Smartcard, in the absence of a hardware 
Smartcard, to authenticate a user. 

59. A computer-implemented metiiod for simulating logging in to a physical 
25 smartcard, comprising: 

prompting, by a di^ conquter, for a password firom a user in response to a client 
application login request; 

sending a message to at least a first server computer which includes a request 
identifying the user, in the absence of sending said password to said server computer, 
30 sending, firom said sep/et computer to said client computer, a smartcard image, at 

least partially encrypted; and 
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sending a niessage to said client application to simulate a response from a physical 
smartcard, using at least some information from said snuurtcard image. 

60. A method, as daimed in claim S9, whmin said smartcard image indudes 
a public key certificate, and fiuther comprising: 

S determining if said public key certificate is expired; 

sending a certification request to a server computer vfhm said public key 
certificate is expired. 

61. A method, as claimed in claim 59, fiirther comprising: 

transmitting information from said client computer to said first server computer 
10 for updating said smartcard image. 

62. Apparatus for simulating logging in to a physical smart-card, comprising: 
means for prompting, by a client computer, for a password from a user in 

response to a client application login request; 

means for sending a message to at least a first server computer which includes a 
15 request identifying the user, in the absence of sending said password to said server 
computer, 

means for sending, from said server compuer to said client computer, a smartcard 
image, at least partially enaypted; and 

means for sending a message to said cEent application to Emulate a response from 
20 a physical anartcard, using at least some information from said smartcard image. 

63. Apparatus for simuiafing logg^lg in to a physical smartcard in a n^work, 
the network induding at least a first client computer coupled, by said network, to at least 
a first server computer, comprising: 

a memory, accessible to said server computer, for storing information 
25 representative of at least a first smartcard image; 

said client and server computers being programmed to 

prompt, by said client computo*, for a password from a user in 
response to a client application login request; 

send a message to at least said first server conqniter which indudes 
30 a request identifying the user, in the absence of sending said password to 

said server compute^ 
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send, from said server compuer to said client computer, a 
smartcard image, at least partially encrypted; and 

send a message to said client application to amulate a response 
from a phyacal anartcard, using at least some information from said 
smartcard image. 
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